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ABSTRACT 


Up  to  a  few  years  ago  the  area  of  software  maintenance  was  largely  ig¬ 
nored.  Interest  has  increased  in  the  last  few  years  due  to  several  factors. 
First,  the  increased  volume  of  enhancement  and  maintenance  with  more  systems 
from  that  of  ten  years  ago  has  restricted  resources  available  for  new  develop¬ 
ment.  Second,  there  has  been  a  growing  awareness  that  tools  and  aids  which 
assist  development  of  information  systems  may  have  little  effect  on  opera¬ 
tional  systems.  Third,  the  management  of  information  systems  has  come  under 
increasing  scrutiny. 

In  this  paper  we  highlight  some  of  the  major  issues  that  surfaced  during 
several  extensive  operational  software  studies.  These  sources  have  pointed  to 
significant  questions  that  must  be  addressed  concerning  the  roles  of  the  users 
in  operations  and  maintenance,  the  management  of  maintenance,  and  the  types  of 
tools  and  techniques  that  are  needed  in  maintenance. 
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1. 


INTRODUCTION 


During  the  past  four  years  an  effort  has  been  made  to  develop  a  better 
understanding  of  software  maintenance  and  enhancement  in  particular  and  opera¬ 
tional  software  in  general.  Several  factors  motivated  this  attention.  First, 
it  has  been  widely  observed  that  software  maintenance  and  operational  support 
consume  substantial  resources  in  the  information  systems  environment.  Al¬ 
though  personnel  consumption  is  the  most  frequently  emphasized,  hardware  and 
system  software  are  also  consumed.  Multiple  versions  of  data  communications 
monitors  and  operating  systems  are  often  needed  to  keep  older  systems  running. 
This  is  due  to  the  inability  of  the  application  software  to  migrate  to  newer 
releases  of  systems  software. 

A  second  factor  is  the  resource  issue  in  general.  Personnel  availability 
is  limited.  Turnover  of  systems  staff  is  a  major  concern  for  many  organiza¬ 
tions  (over  30%  per  year  in  some  organizations).  In  the  area  of  operational 
software  turnover  of  maintenance  personnel  can  result  in  reduced  support  of 
the  application  system  and  even  result  in  damage  as  untrained  or  unfamiliar 
staff  attempt  to  grapple  wtih  a  particular  enhancement  or  maintenence  fix. 

A  third  factor  is  the  sense  that  much  of  the  software  engineering  and 
computer  science  research  has  not  touched  on  the  problems  associated  with 
maintenance  and  operations.  Research  has  produced  many  development  tools  and 
techniques.  Some  of  these  have  substantial  merit.  However,  these  tools  are 
not  easily  transferred  into  a  maintenance  environment  involving  large  scale 
operational  applications  which  are  over  five  years  old.  There  is  not  enough 
resources  to  rewrite  the  software  using  the  new  tools. 


2 


2.  RESEARCH  METHODS 


The  research  program  began  with  a  small  scale  survey  of  less  than  one 
hundred  systems.  The  results  were  reported  in  LIET78.  The  survey  was  based 
on  a  fifteen  page  questionnaire  mailed  to  firms  in  the  western  United  States. 
Several  interesting  results  emerged  from  the  survey.  First,  maintenance  and 
enhancement  were  found  to  consume  approximately  half  of  the  systems  and  pro¬ 
gramming  personnel  hours.  Approximately  60%  of  the  effort  was  in  the  area  of 
perfective  maintenance  (i.e.  ,  system  enhancements,  improved  documentation,  and 
recoding  for  efficiency).  This  finding  was  somewhat  unexpected  since  the 
literature  had  supported  the  belief  that  fixing  programs  and  keeping  systems 
operational  were  the  major  concerns.  A  third  finding  was  that  problems  of  a 
managerial  nature  were  viewed  as  more  significant  than  those  of  a  technical 
type. 


An  applied  research  program  was, initiated  to  determine  what  studies  and 


analyses  had  been  carried  out.  A  literature  search  proved  somewhat  dishearten¬ 
ing.  With  few  exceptions  the  meager  literature  was  based  on  extremely  small 
sample  sizes.  From  such  limited  data  very  substantial  conclusions  were  drawn. 
Some  of  these  in  retrospect  are  worth  reviewing.  There  is  the  hypothesis  that 
maintenance  burdens  continue  to  grow  unabated.  There  is  the  feeling  that 
staff  morale  and  motivation  in  maintenance  are  very  low.  A  third  hypothesis 
was  that  development  tools  could  be  used  to  reduce  maintenance  costs  Overall 
the  hypotheses  centered  on  the  technical  aspects  of  maintenance.  The  reader 
is  referred  to  the  papers  8ELL76,  B0EH75,  B0EI76  and  CANN72  for  some  of  the 
more  interesting  findings. 

Interest  in  maintenance  was  also  increased  as  a  result  of  this  study. 
Individuals  contacted  during  the  survey  continued  to  pursue  analysis.  "Several 
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organizations  adopted  changes  suggested  as  a  result  of  the  research.  These 
factors  and  the  small  sample  size  encouraged  a  larger  sample  size  survey. 

A  larger  survey  consisted  of  a  sample  of  two  thousand  management  members 
of  the  Data  Processing  Management  Association  (OPMA).  This  organization  was 
selected  because  it  has  the  largest  percentage  of  membership  based  in  systems 
personnel  in  industrial  positions.  The  survey  methodology  and  results  are 
contained  in  the  book  LIES80.  Summary  results  and  other  finding  have  been 
presented  in  LIES78,  LIES82.  For  background  it  is  useful  to  highlight  the 
methodology  employed  in  this  larger  sample. 

The  OPMA  Foundation  provided  a  randomly  generated  subset  of  the  ten 
thousand  members  who  classify  their  jobs  in  management.  The  questionnaire  was 
accompanied  by  an  endorsement  letter  by  the  OPMA  Foundation.  Return  envelopes 
and  followup  postcards  were  used  to  encourage  response.  There  were  486  valid 
responses.  This  is  quite  remarkable  considering  that  the  questionnaire  was 
lengthy  (over  17  pages)  and  conducted  by  mail.  The  data  was  entered  into  a 
computer  and  analyzed  using  the  statistical  routines  in  SPSS.  Some  of  the 
major  issues  that  surfaced  are  discussed  in  the  next  section. 

These  surveys  were  conducted  with  a  base  consisting  mainly  of  business 
systems  as  opposed  to  real  time,  sensor  based  systms.  With  factory  automa¬ 
tion,  improvements  in  command  and  control,  and  increased  on-line  systems  it 


was  felt  that  the  methodology  should  be  applied  to  this  group  of  systems. 
In  1980  a  limited  study  was  undertaken  for  the  Office  of  the  Assistant 


Secretary  of  the  Navy  of  eighteen  weapon  systems  by  P.  Wegner  and  the  author 
(LIEW81).  Each  software  weapon  system  is  in  operational  use  for  a  particular 
Navy  airplane,  missile,  or  ship  class.  Most  of  these  systems  were  real  time, 
fed  by  sensors  and/or  radar.  The  results  of  this  study  confirmed  the  findings 
of  the  larger  previous  study. 


The  questionnaires  used  in  the  surveys  were  divided  into  two  parts.  One 
part  focused  on  the  organization  and  how  maintenance  was  carried  out  in  gen¬ 
eral.  The  second  part  centered  on  an  application.  The  application  system 
selected  by  the  respondent  had  to  satisfy  three  criteria:  (1)  the  system  must 
have  been  in  operation  at  least  one  year;  (2)  there  must  be  significant  main¬ 
tenance  work  attached  to  the  system;  (3)  the  system  must  be  of  major  impor¬ 
tance  to  the  organization. 

To  identify  issues  from  the  data  several  methods  were  employed.  At  the 
end  of  the  questionnaire  was  a  list  of  problem  factors  that  have  been  men¬ 
tioned  in  the  literature  or  inferred  in  previous  versions  of  the  questionnaire. 
This  list  of  problems  grew  from  twenty  in  the  first  version  to  over  thirty  in 
the  latest  version.  The  thirty  areas  included  management  and  user  oriented  as 
well  as  technical  issues. 

In  the  next  section  we  summarize  the  issues  and  problems  that  have  been 
discovered  in  the  areas  of  application  software  maintenance  and  operation. 
Section  3  presents  a  possible  framework  or  an  approach  and  suggests  specific 


areas  where  further  work  is  needed. 

To  assess  quality  of  response  for  many  questions  which  asked  for  quanti¬ 
tative  answers  respondents  were  asked  to  assess  the  quality  of  the  response 
(reasonably  accurate,  based  on  good  data;  rough  estimate,  based  on  numeral 
data;  best  guess,  not  based  on  any  data).  This  is  a  measure  of  the  knowledge 
about  the  system  in  a  snapshot-  mode. 

A  question  was  also  asked  about  controls  in  place  in  the  system.  These 
were  for  controls  regularly  employed  and  in  place.  Included  here  were  such 
controls  as  logging  request,  cost  justification  of  change,  trouble  logging, 
formal  audit,  and  charge  back  of  costs  (equipment  and  personnel).  The  later 
survey  added  specific  controls  for  Oefense  Department  Standards. 
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Beyond  these  direct  methods  of  identifying  issues  and  how  systems  were 
measured  and  controlled,  there  are  also  a  number  of  indirect  measures  based  on 
other  data.  For  example  the  size  aspects  of  the  system  were  asked  for  current 
and  for  one  or  two  previous  years.  This  revealed  an  interesting  longitudinal 
view  of  maintenance. 

It  is  also  possible  to  interpret  and  extract  issues  from  the  number  of 
people  who  work  on  the  system,  the  number  who  worked  on  the  system  in  develop¬ 
ment  and  are  still  working  with  it  in  maintenance,  and  the  percentage  of 
effort  in  various  maintenance  and  enhancement  tasks. 

3.  ISSUES  AND  PROBLEMS  IN  APPLICATION  SOFTWARE  MAINTENANCE 

Ir,  the  surveys  five  areas  of  issues  have  emerged  as  dominant  and  compre¬ 
hensive.  We  will  consider  each  of  these  in  terms  of  research  as  well  as 
I uipl cfnenLat'i on  concerns , 

3.1  Conceptual  Issues 

At  the  heart  of  maintenance  is  its  very  definition.  In  the  surveys  an 
inclusive  definition  was  employed.  Such  a  definition  includes  enhancements 
and  operational  support  as  part  of  maintenance  along  with  routine  debugging 
and  problem  identification  and  resolution.  More  specifically,  the  question¬ 
naires  in  the  larger  commercial  survey  and  weapons  survey  included  as  main¬ 
tenance  emergency  fixes,  routine  debugging,  accommodations  of  changes  in 
file/data  input,  accommodation  to  hardware/software  change,  enhancements, 
documentation  improvement,  ana  recoding  for  efficiency.  Enhancements  were 
divided  into  new  reports,  adding  data,  refcrmating,  consolidation,  file  expan¬ 
sion  and  condensation  of  data.  There  are  psychological  impacts  based  on  a 


possible  derogatory  implication  of  the  work  maintenance.  However,  the  inclu¬ 
sionary  definition  helps  to  aggregate  the  support  needed  for  an  operational 
application  system.  The  research  has  shown  in  all  three  studies  that  enhance¬ 
ments  for  users  are  the  major  acitvity  (50-70%  of  the  total  of  maintenance  and 
enhancement).  Adaptation  to  new  technology  surfaced  only  in  the  weapons 
systems  survey  as  a  major  activity.  Emergency  fixes  and  recoding  for  effi¬ 
ciency  were  relatively  minor  in  resource  utilization  (less  than  20%)  as  was 
documentation  (less  than  5%). 

Associated  with  the  definition  of  maintenance  is  the  extensive  continued 
development  of  an  application  system.  For  many  systems  there  appears  to  be  no 
single  life  cycle.  Rather  the  life  cycle  appears  to  repeat  itself.  The  data 
appeared  to  support  the  view  that  once  develoDtnent  was  complete  and  the  system 
stabilized  in  operational  use,  enhancements  began  individually  or  in  groups 
( i n by  the  snapshot  of  two  time  periods  (present  and  one  year  prior)  in 
the  questionnaire.  The  data  indicated  that  while  total  maintenance  in  the 
organization  is  approximately  the  same  as  development,  maintenance  on  particu¬ 
lar  systems  declined  as  the  initial  operational  errors  were  fixed  and  then 
increased  as  users  requested  enhancements.  The  author  has  worked  with  a 
number  of  systems  projects  and  groups  and  has  seen  this  first  hand.  Belady 
also  refers  to  it  in  systems  software.  However,  the  data  was  not  sufficient 
to  fully  support  this  hypothesis.  If  the  hypothesis  holds  for  a  particular 
system,  then  as  users  request  new  enhancements,  a  new  developmental  cycle  is 
begun. 

What  is  needed  in  the  conceptual  framework  of  maintenance  is  a  complete 
classification  of  the  tasks  and  work  done  under  the  maintenance  umbrella. 
SWAN76  has  begun  this  work.  It  needs  to  be  further  refined.  While  the  con¬ 
cept  of  maintenance  appears  academic,  there  are  substantial  practical  implica¬ 
tions  as  well.  A  classification  method  could  be  used  to  assist  project 
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control  systems.  The  classification  into  perfective,  adaptive,  and  corrective 
maintenance  is  now  in  use  in  a  number  of  organizations  and  has  proved  benefi¬ 
cial  in  cost  estimation  by  task  and  type  of  system.  Systems  groups  increas¬ 
ingly  are  charging  back  their  costs  to  user  organizations.  A  necessary  part 
of  the  foundation  is  fairly  accurate  estimation  of  costs.  The  data  and  classi¬ 
fication  method  assist  in  this  task. 

3.2  Measurement  Issues 

Beyond  maintenance  is  the  issue  of  how  to  measure  a  system.  We  are  not 
concerned  here  with  systems  measurement  in  general.  Rather  we  are  concerned 
with  measurement  during  maintenance  itself.  The  surveys  indicated  that  sys¬ 
tems  with  very  similar  sizes  revealed  entirely  different  patterns  of  main¬ 
tenance  activity.  The  findings  of  the  surveys  shed  light  on  an  expanded 
measurement  approach.  The  findings  revealed  the  key  role  of  the  user  and 
manager  in  maintenance  activities.  This  suggests  that  measurement  of  software 
should  be  done  externally  as  well  as  internally. 

To  explore  change  sources  it  is  useful  to  consider  the  environment  of  an 
application  system.  There  are  four  basic  parts  of  the  environment  which  can 
affect  a  system. 

-  User  external 

This  environment  includes  legislation,  competitive  pressures,  social  and 
cultural  factors.  It  also  includes  the  internal  user  organization  and  staff¬ 
ing.  There  are  quantitative  factors  here  which  can  be  gathered.  The  requests 
for  change  can  be  classified  as  to  their  ultimate  source.  The  number  of  users 
actively  working  with  the  system  can  be  measured.  It  is  clear  from  the  data 
processing  surveys  that  this  area  has  been  overlooked. 
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-  Technological 

Technological  change  can  affect  applications.  Distributed  data  process¬ 
ing  can  result  in  the  split  of  an  application  across  multiple  computer  systems. 
New,  more  intelligent  terminals  may  have  the  same  impact.  Technology  may  also 
make  it  possible  to  join  or  tie  together  separate  applications. 

*  Managerial 

Management  pressure  is  frequently  exerted  to  control  costs  and  to  modify 
schedules.  This  pressure  can  directly  impact  the  maintenance  effort  and  its 
quality.  It  is  one  reason  why  documentation  of  changes  is  frequently  not  done 
or  is  insufficient.  Managerial  pressure  also  focuses  on  the  short  term. 
There  is  a  lack  of  attention  to  fundamental  rework  of  application  systems 
using  new  techniques.  Who  wants  to  expend  the  effort  to  rework  something  that 
works?  This  in  turn  prevents  the  use  of  productivity  aids.  System  size  gets 
larger  as  enhancement  piles  upon  enhancement.  The  surveys  reveal,  not  unex¬ 
pectedly,  that  systems  become  more  comple.'".  and  difficult  to  maintain  as  they 
age.  They  grow  in  size  and  complexity.  The  original  staff  that  know  the 
application  attrition  out  of  the  organization. 

-  Marketplace 

The  marketplace  produces  new  products  and  services  as  we  have  noted  in 
technology.  It  also  creates  a  competition  for  personnel,  exerting  more  pres¬ 
sure  on  the  maintenance  staff.  Furthermore,  new  products  and  services  may 
spur  the  users  to  request  more  enhancements. 

3. 3  Scale  of  Effort 

The  contention  in  the  past  has  been  that  the  percentage  in  maintenance  is 
steadily  increasing.  The  surveys  do  not  bear  this  out.  The  data  indicates 
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that  the  percentage  is  relatively  stable  in  most  organizations  -  about  50%  o 
the  effort.  However,  there  are  organizations  in  the  samples  which  repor 
sharply  rising  percentages  over  a  two  year  period.  The  respondents  in  severa 
instances  indicated  that  controls  are  exerted  by  management  to  reduce  th 
percentage.  Thus,  it  appears  that  scale  of  effort  is  heavily  dependent  on  th 
organizational  environment  and  the  portfolio  of  application  systems  bein 
developed  and  maintained  at  a  given  time. 

3.4  Organizational  Issues 

In  the  past  interest  has  centered  on  the  organization  of  maintenanc. 
within  a  systems  group.  Questions  that  arise  are  whether  it  should  be  sepa 
rated  or  combined  with  development.  However,  given  the  rising  interest  an. 
impact  of  the  user  community  it  might  be  well  to  consider  more  global  issues 
What  is  the  role  of  the  users  in  maintenance  and  enhancement?  Should  users  bt 
given  report  generators  and  other  aids?  Should  users  be  responsible  foi 
production?  After  all  this  is  true  today  in  a  number  of  minicomputer  base* 
on-line  systems. 

The  role  of  users  is  a  major  issue  for  systems  groups  in  general.  Natioi 
ally  there  is  a  shortage  of  20-30%  in  systems  personnel.  Users  may  have  . 
role  in  filling  the  gap  between  supply  and  demand.  This  is  happening  today  if 
many  organizations  and  likely  to  continue  as  delays  lengthen  due  to  staf’ 
shortages.  Thus,  the  user  role  in  maintenance,  enhancement,  and  operation; 
needs  to  be  assessed  in  general, 

A  separate,  but  related  organizational  issue  is  that  of  controls  for  th* 
system.  The  surveys  ir.  the  commercial  sector  reveal  that  many  controls  thai 
are  supported  in  education  and  theory  are  not  used  in  practice.  The  issut 
here  is  the  trade-off  between  the  benefits  of  the  controls  and  the  cost  ot 
their  control  and  implementation.  Also,  many  organizations  lack  the  technical 
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implementation  aids  that  make  such  controls  bearable.  The  issue  here  is  to 
determine  which  groups  of  controls  are  appropriate  to  each  category  of  applica 
tion  systems. 

3.5  Productivity  Issues 

A  main  research  focus  has  been  the  productivity  of  programmers  and  to  a 
lesser  extent  analysts  in  the  systems  organization.  A  variety  of  techniques 
have  been  devised.  The  surveys  reveal  only  linited  use.  Furthermore,  in 
cases  where  they  are  employed  the  results  form  the  survey  are  not  signifi¬ 
cantly  different  from  traditional  methods.  It  should  be  emphasized  that  there 
was  no  control  or  verification  of  the  techniques  among  the  respondents. 

But  is  the  productivity  of  programmers  the  major  concern?  The  findings 
cited  in  the  survey  results  and  what  we  already  discussed  point  to  the  user 
and  manager  areas.  There  are  far  more  users  than  developers  or  maintainers. 

Thus,  if  a  productivity  technique  can  be  found  for  a  user  function,  its  effect 

«• 

is  multiplied  far  more  than  that  for  programmers.  This  also  relates  to  the 
role  of  the  user  that  was  discussed  earlier.  Productivity  of  users  which  are 
performing  less  complex  tasks  may  be  easier  to  achieve  than  aiding  a  program¬ 
mer  with  a  complex  task. 

A  second  area  of  productivity  tools  has  focused  on  the  analysis  and 
design  stages  of  system  development  and  enhancement.  These  tools  aim  at 
improving  the  design  correctness  and  completeness.  The  thought  here  is  that 
by  nailing  down  the  requirements,  the  system  will  be  easier  to  maintain  and 
will  more  completely  meet  the  user  needs.  This  view  of  the  world  was  probably 
valid  at  a  time  when  systems  were  batch  oriented  and  when  users  were  not 
involved  with  systems.  Today  the  situation  is  changed.  User  management 
pressures  users  to  automate  to  control  user  organization  costs.  Requirements 
which  in  the  past  were  more  stable  are  so  no  longer.  In  many  areas  there  are 
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substantial  changes  each  year  that  result  in  major  enhancements  and  retrofit¬ 
ting. 

4.  Perceived  Problem  Areas 

The  major  surveys  provided  respondents  with  26  potential  problem  areas  in 
maintenance.  The  respondents  were  asked  to  rank  these  on  a  scale  of  i  (no 
problem)  to  5  (major  problem).  A  variety  of  problem  areas  were  listed  and  are 
summarized  in  Figure  1.  The  six  problems  seen  as  most  severe  were: 

Quality  of  application  system  documentation. 

User  demand  for  enhancements  and  extensions. 

Competing  demands  for  maintenance  programmer  personnel  time. 

Meeting  scheduled  commitments. 

Turnover  in  user  organization. 

Of  the  six  problems  seen  as  most  severe,  three  are  concerned  with  users,  two 
with  the  management  function  of  apportioning  resources,  and  one  (documenta¬ 
tion)  with  a  technical  issue  —  albeit  not  one  relating  to  programming.  The 
predominance  of  non-technical  issues  is  striking. 

Statistical  analysis  uncovered  six  main  groupings  of  problem  areas: 
-  User  knowledge  (11,  25) 

Programmer  effectiveness  (16,  14,  5) 

Product  quality  (22,  6,  2) 

Programmer  time  availability  (8) 

Machine  requirements  (12,  13) 

System  reliability  (17,  18) 

Components  are  given  in  Table  1. 

Additional  statistical  factor  analysis  was  performed  to  determine  which 
factors  contributed  to  the  variance.  The  ranking  was  as  that  given  above  with 


FIGURE  1:  POTENTIAL  PROBLEM  FACTORS  IN  MAINTENANCE  SURVEYS 


Ranking 

(Large  Ranking 

Commercial  Sample)  (Weapons  Systems) 


1.  Maintenance  personnel  turnovei - * — -  14 

2.  Documentation  quality - - -  3 

3.  System  hardware  and  software  changes -  17 

4.  Demand  for  enhancements  and  extensions -  1 

5.  Skills  of  maintenance  programmers -  16 

6.  Quality  of  original  programming - - -  7 

7.  Number  of  maintenance  programmers 

available -  8 

8.  Competing  demands  for  programmer  time -  2 

9.  Lack  of  user  interest- -  23 

10.  System  run  failures - 24 

11.  Lack  of  user  understanding -  6 

12.  Program  storage  requirements - - -  19 

13.  Program  processing  time  requirements -  9 

14.  Maintenance  programmer  motivation -  21 

15.  forecasting  maintenance  programming 

requirements -  11 

16.  Maintenance  programming  productivity-— — —  18 

17.  System  hardware  and  software  reliability —  26 

18.  Data  integrity -  22 

19.  Unrealistic  user  expectations -  10 

20.  Adherence  to  programming  standards -  15 

21.  Management  support - 25 

22.  Adequacy  of  system  design  specifications---  12 

23.  Budgetary  pressures -  20 

24.  Meeting  scheduled  commitments -  5 

25.  Inadequate  user  training -  4 

26.  Turnover  in  user  organizations -  13 
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user  knowledge  as  the  major  component  at  b9.5%  followed  by  programmer  effec¬ 
tiveness  at  11.9%.  User  knowledge  includes  user  training  and  uer  expectation 
for  changes  as  well  as  a  lack  of  user  understanding.  Programming  effective¬ 
ness  includes  skills  of  programmers  as  well  as  their  productivity.  In  the 
surveys  several  potential  problem  areas  which  have  been  widely  mentioned  as 
concerns  in  the  literature  failed  to  be  significant.  These  included  process¬ 
ing  and  storage  requirements,  data  integrity  and  hardware/software  reliability. 
Migration  across  to  new  generations  of  hardware  was  not  viewed  as  significant. 
This  is  partially  because  the  manufacturers  often  provide  software  to  aid  such 
migration. 

Some  interesting  observations  appear  from  the  data  for  this  question.  Of 
the  top  three  problems  only  one  (documentation  quality)  emerges  as  more  than  a 
minor  problem  in  the  technical  area.  The  largest  problem  in  ranking  is  user 
demand.  Second  is  competing  demand  for  personnel  time.  This  relates  to  the 
role  of  users  in  maintenance  and  enhancement.  If  users  were  involved  in  more 
activities  their  understanding  would  improve,  perhaps,  impacting  demand.  In 
many  organizations  a  small  number  of  people  are  significant  resources  for  a 
range  of  systems  and  tasks  -  making  competition  for  their  time  more  intense. 

Of  the  top  sixteen  items  (that  which  ranked  above  2  on  the  scale  of  1  to 
5)  six  are  management  oriented,  five  are  user  oriented,  and  five  are  technical. 
Of  the  remaining  ten  all  but  two  are  technical. 

In  the  same  figure  are  the  rankings  for  the  military  systems.  These 
systems  largely  depend  on  hardware  which  is  older  and  limited  in  capabilities. 
This  accounts  for  the  significance  given  to  technical  hardware  and  software 
issues.  A  hypothesis  is  that  data  for  many  on-line  systems  which  are  at  the 
hub  of  the  business  organization  (e.g. ,  demand  deposit,  on-line  reservations) 
would  probably  be  similar.  User  issues  include  testing  due  to  the  limited 
constraints  within  which  the  application  software  must  function. 


Personnel  turnover  impact  was  viewed  as  significant  when  turnover  oc¬ 


curred.  This  is  due  to  the  correlation  found  between  the  experience  and  time 
spent  with  the  application  system  being  inversely  related  to  the  degree  to 
which  maintenance  of  the  system  was  perceived  to  be  a  problem.  Maintenance 
effort  was  also  found  to  negatively  correlate  with  the  time  spent  with  the 
system. 

With  these  problem  areas  highliynted  we  can  turn  again  to  the  productiv¬ 
ity  aids.  Most  of  the  aids  that  have  been  developed  to  date  (e.g.,  structured 
programming,  HIPO,  structured  walk-through,  etc.)  have  limited  impact.  In 
LIE480  and  LIEW81  the  use  of  tools  such  as  structured  programming,  design, 
test  tools,  automated  documentation,  and  other  tools  was  assessed.  The  re¬ 
sults  indicated  that  no  tool  was  used  in  over  30%  of  either  survey.  Further¬ 
more  the  use  or  non-use  of  tools  had  little  impact  on  the  total  amount  of 
maintenance  and  enhancement  except  to  slightly  increase  resources  for  enhance¬ 
ments.  The  problem  with  tods  is  that  it  is  too  expensive  and  costly  to 
retrofit  the  system  to  take  advantage  of  the  tools.  Further,  many  tools 
appear  to  gain  and  then  dim  in  acceptance.  Yet  application  system  maintenance 
must  continue  sometimes  long  after  the  software  tool  or  methodology  technique 
has  dropped  from  favor. 


5.  CONCLUSIONS 

While  much  more  research  is  needed  in  maintenance,  the  work  thus  far 
indicates  that  in  the  future  consideration  will  need  to  be  given  to  main¬ 
tenance  in  the  user  area  as  well  as  systems.  Application  systems  maintenance 
will  continue  as  an  area  of  concern,  but  will  be  more  focused  on  substantial 
enhancement  and  maintenance.  Table  2  indicates  some  of  the  activities  of 


user,  operations,  and  system  responsibility. 


Since  we  are  just,  now  involving  users  on  a  larger  scale,  we  have  the 

opportunity  to  organize  and  control  or  coordinate  user  activities.  Figure  1 

shows  some  of  the  user  report  activities.  The  need  for  user  operated  and 

managed  tools,  techniques,  and  aids  will  grow.  These  responsibilities  are 

likely  to  be  more  structured  than  informal  decision  support  systems  since  they 

will  be  exercised  in  conjunction  with  routine  data  processing  and  everyday 

business  enterprises.  Some  of  the  issues  in  user  maintenance  tuat  may  arise 

are:  documentation,  interfaces  to  base  system  (maintained  by  systems),  use  of 

microcomputer  software  with  base  system  data,  data  quality,  retention  and 

recovery,  user  productivity,  verification  and  testing,  and  technology  transfer. 

Thus,  a  dual  maintenance  framework  may  emerge:  one  for  the  base  systems 

emphasizing  efficiency  and  control,  perhaps,  and  one  for  user  maintained 

C  w*vt*rr 

functions  and  systems  supporting  effectiveness  and  goodness  of  fit  to  cement 
organizational  needs. 
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TABLE  1 

PROBLEM  FACTORS  AND  THEIR  COMPONENTS 


User  knowledge. 

Lack  of  user  understanding  of  application  system. 

Inadequate  training  of  use  personnel. 

Programmer  effectiveness. 

Maintenance  programming  productivity. 

Motivation  of  maintenance  programming  personnel. 

Skills  of  maintenance  programming  personnel. 

Product  quality. 

Adequacy  of  application  system  design  specifications. 

Quality  of  original  programming  of  application  system. 

Quality  of  application  system  documentation. 

Programmer  time  availability. 

Competing  demands  for  maintenance  programming  personnel  time. 

Machine  reguirements. 

Storage  requirements  of  application  systems  programs. 
Processing  time  requirements  of  apolication  system  programs. 

System  reliability. 

System  hardware  and  software  reliability. 

Oata  integrity  in  application  system. 


TABLE  2 


RESPONSIBILITY  FOR  MAINTENANCE  AREAS 


AREA  /  ACTIVITY 


USERS  SYSTEMS 


Production 

Data  entry 
Inquiry 

Production  initiation 
Batch 
On-line 

Fixing  problems 


X 

X 


X 


X 


Enhancements 

Report  generation 
Addition  of  new  date  elements 
Addition  of  new  functions 
Modification  of  reports 
Modification  of  system  tables 
Requirements  analysis 
Oesign 


X 

X 

X 

X 

X 


X 

X 

X 


Maintenance 

Recoding  for  efficiency  X 
Improving  documentation  X  X 
Accommodate  changes  in  hardware  /  software'  X 
Accommodate  changes  in  files  X 
Accommodate  changes  in  input  data  X 


Management 

Monitoring  of  change  requests 
Project  control 
Cost  accounting 


X 

X 


X 

X 

X 


OPERATIONS 

X 

X 


X 

X 


USER  ENHANCEMENTS  BY  TYPE 

(487  DPAAA  member  organizations) 


Oaia  from: 

lientz.  8-P  ,  Swanson,  E.B. 

Software  maintenance  management — c  study  of  the  maintenance  of  computer  cpp/'cancn 
software  in  487  data  processing  organizations. 

Reading,  MA:  Addison-Wesley  Publishing  Company,  1980. 
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lIn  this  report  we  highlight  some  of  the  major  issues  that  surfaced  during 
several  extensive  operational  software  studies.  These  sources  have  pointed 
to  significant  questions  that  must  be  addressed  concerning  the  roles  of  the 
users  in  operations  and  maintenance,  the  management  of  maintenance,  and  the 
types  of  tools  and  techniques  that  are  needed  in  maintenance,^ 


